在上一篇文章中，我们给大家介绍了团队规范的优点，然后给大家推荐了几种命名规范方式。然后，着重给大家介绍了 UI 设计规范。首先介绍了 UI 设计规范的优点，其不仅可以培养用户心智、减少用户学习成本、让人机交互更加自然，还可以提高开发效率和项目的可维护性。然后从基础设计元素和组件两个方面介绍了 UI 设计规范的范围，最后具体说明了如何将规范进行落地，最后以 Button 组件为例，示范了怎么将 UI 设计规范应用在具体的开发中。

本篇文章我们就继续聊下其余的前端团队规范，主要包括项目结构规范、团队 workflow、和 git commit 规范。

# 项目结构规范

项目结构规范包括文件命名、文件目录组织方式。一个项目的文件结构就像是一本书的目录，是其他开发者了解项目最快的方法。代码的组织方式，也是项目架构设计的体现，比如如何划分视图层、控制层等。如果你是项目的创建者，那么你需要好好设计项目的文件结构和代码的组织方式，框架搭好了，再加砖添瓦就容易了。如果你是项目的维护者，那么你需要遵守项目的文件结构规范，风格统一了后续才好维护，同时也避免了公共函数\组件重复开发的问题。

对于文件目录组织方式，通常我们会在根目录下，按照职能进行划分出多个目录。以 Vue 举例，一般的 Vue 项目一级目录内容如下：

• 存放公共资源的 public目录（该文件内容不会被 webpack 处理)；
• 用来存放源代码资源的src目录；
• 用于存放测试用例的 tests目录；
• 还有自动安装的依赖 node_modules。

除了这些一级目录之外，还会有一些配置文件，比如 TS 的配置文件tsconfig.json 、babel 的配置文件 babel.config.js等，还有一些项目文档，比如说明文档 README.md。一个常见的 vue 项目的一级目录结构如下：

.
├── node_modules
├── public
├── src
├── tests
├── README.md
├── package-lock.json
├── package.json
├── babel.config.js
└── tsconfig.json

src 又可以细分为用于接口请求的api 目录、存放静态资源的目录 assets、存放公共组件的目录 components、存放样式文件的目录 styles、项目的路由统一存放在router 中、页面统一存储的变量store、一个公共工具utils、项目的视图集合views。

├─api （接口）
├─assets （静态资源）
├─components （公共组件）
├─styles （样式）
├─router （路由）
├─store （vuex）
├─utils （工具函数）
└─views （页面）

项目结构看似很简单，但确是在项目创建初期要仔细思考的问题。项目结构混乱，就如同一本书的目录混乱，目录混乱那么你项目的“读者”能快速争取的理解项目的内容吗？建立统一的目录结构和规范的命名方式有助于其他人快速找到需要的资源。

# 工作流程 workflow

编写代码，是软件开发交付过程的起点，发布上线，是开发工作完成的终点。代码分支模式贯穿了开发、集成和发布的整个过程，是工程师们最亲切的小伙伴。那如何根据自身的业务特点和团队规模来选择适合的分支模式呢？又如何进行多人代码管理呢？

说到分支管理和代码协作，首先想到的就是 Git，Git 是我们用到版本控制工具。主流的版本控制工具有两款：Git 和 svn。svn 的理念是集中式，必须要把代码提交到中心控制器。而 Git 的理念是分布式，每一个开发者在本地都有一个 Git 仓库。因为现在大部分公司或者个人使用 Git，所以在这里我们主要介绍 Git 相关的工作流程。

Git workflow 是有关如何使用 Git 以高效协作开发的规则或策略建议，下文这些常见工作流程只是作为指导参考，这些工作流不是一成不变的，我们应该根据自己的项目选择或制定合适自己的工作流。

我们先来了解下在 workflow 中常见的发布模式和分支模式。

# 发布模式

我们常见的发布模式有两种：

• 一种是有明确版本规划、需要有多个版本支持的“版本发布”模式，常用于终端类产品，比如我们常见的手机上的 APP 就是其中一种。
• 另一种是一个功能分支开发完毕没有问题后就立即可以发布上线的“持续发布”模式，常用于网页产品，因为其迭代快、无需审核，只需要关注最新版本即可。

# 分支模式

一般情况下，在开发的过程中，我们会使用到以下几种不同类型的分支：

• master：主干分支，一个项目应该有且只有一个主干分支，并且为 protected 分支。作为最稳定的分支，通常情况是线上环境运行的分支。不能在 master 分支上直接开发，只能被其他分支合入。
• develop：开发分支，在不同的 workflow 中有不同的用途。
• feature：功能分支，针对每个功能创建一个 feature 分支进行独立开发。
• hotfix：bug 修复分支，针对已合并的功能分支有需要修复的 bug ，就创建一个 hotfix 分支。
• release：预发分支，在正式发版之前，需要一个预发布版本进行回归测试。

# 主流 workflow

在了解了常见的发布模式和分支模式之后，我们再看下传统的主流的 workflow。传统的主流 workflow 有三种：

• git flow
• github flow
• gitlab flow

我们分别来简单介绍下。

# git flow

git flow 是诞生最早的一种 workflow。git flow 工作流下会长期存在两个稳定分支，develop 和 master。master 分支是生产环境运行的分支。而 develop 分支是待上线分支，包含了待上线的功能。大多数情况下，develop 分支的代码会领先 master 分支。

在新迭代开始的时候，会先从 develop 分支中拉取出 feature 或者 hotfix 分支用来平时的开发和 bug 的修复工作，开发完成后，会先将 feature 或 hotfix 合入 develop。然后根据发布计划，将 develop 分支合并到 master 分支进行版本发布的操作。具体工作流程如下图：